home *** CD-ROM | disk | FTP | other *** search
/ Aminet 25 / Aminet 25 (1998)(GTI - Schatztruhe)[!][Jun 1998].iso / Aminet / dev / amos / AMOS0398.lzh / AMOSLIST / 000105_amos-request@svcs1.digex.net_Tue Mar 10 01:12:28 1998.msg < prev    next >
Text File  |  1998-04-01  |  4KB  |  85 lines
  1. >From amos-request@svcs1.digex.net  Tue Mar 10 01:12:27 1998
  2. Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224])
  3.     by pony-2.mail.digex.net (8.8.8/8.8.8) with ESMTP id BAA17275
  4.     for <mcox@access.digex.net>; Tue, 10 Mar 1998 01:12:27 -0500 (EST)
  5. Received: (from daemon@localhost)
  6.     by svcs1.digex.net (8.8.5/8.8.5) id VAA25151
  7.     for amos-out; Mon, 9 Mar 1998 21:41:46 -0500 (EST)
  8. Received: from pony-1.mail.digex.net (pony-1.mail.digex.net [204.91.241.5])
  9.     by svcs1.digex.net (8.8.5/8.8.5) with ESMTP id VAA25148
  10.     for <amos-list@svcs1.digex.net>; Mon, 9 Mar 1998 21:41:45 -0500 (EST)
  11. Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3])
  12.     by pony-1.mail.digex.net (8.8.8/8.8.8) with ESMTP id VAA21236
  13.     for <amos-list@access.digex.net>; Mon, 9 Mar 1998 21:41:44 -0500 (EST)
  14. Received: from midway.uchicago.edu (root@midway.uchicago.edu [128.135.12.12])
  15.     by haven.uchicago.edu (8.8.5/8.8.5) with ESMTP id UAA01106
  16.     for <amos-list@access.digex.net>; Mon, 9 Mar 1998 20:41:43 -0600 (CST)
  17. Received: from harper.uchicago.edu (15273@harper.uchicago.edu [128.135.12.7]) by midway.uchicago.edu (8.8.5/8.8.3) with ESMTP id UAA13286 for <amos-list@access.digex.net>; Mon, 9 Mar 1998 20:40:11 -0600 (CST)
  18. Received: from localhost (sdmatott@localhost) by harper.uchicago.edu (8.8.5/8.8.3) with SMTP id UAA29736 for <amos-list@access.digex.net>; Mon, 9 Mar 1998 20:40:09 -0600 (CST)
  19. X-Authentication-Warning: harper.uchicago.edu: sdmatott owned process doing -bs
  20. Date: Mon, 9 Mar 1998 20:40:09 -0600 (CST)
  21. From: "Scooter D. Matott sXe" <sdmatott@midway.uchicago.edu>
  22. X-Sender: sdmatott@harper.uchicago.edu
  23. To: Amos List <amos-list@access.digex.net>
  24. Subject: Re: Out of Stack?
  25. In-Reply-To: <3.0.2.32.19980309142555.0069facc@radiks.net>
  26. Message-ID: <Pine.GSO.3.95.980309202051.22269B-100000@harper.uchicago.edu>
  27. MIME-Version: 1.0
  28. Content-Type: TEXT/PLAIN; charset=US-ASCII
  29. Status: O
  30. X-Status: 
  31.  
  32.  
  33. > Hey again, 
  34. > I have a little question..
  35. > why does this cause me to get an "Out of stack space" Error and what can I
  36. > do to remedy it?
  37. > Thanx in advatz!!! :)
  38.  
  39.     This is a classic programing pit fall, every time you jump to
  40. one procedure from within another, all the data (variables) from the
  41. procedure you are leaving are tossed on the 'stack' basically they are
  42. stored in quick temporary memory so they can be recalled quickly when you
  43. return to the original procedure.
  44.  
  45. ex.
  46. Procedure FUN_TIMES
  47. x=100
  48. y=320
  49. ght=345
  50.  
  51. Proc GOOD_TIMES
  52.  
  53. End Proc
  54.  
  55.     Now when the program hops to GOOD_TIMES in that last line all the
  56. variables (x,y,ght) are thrown on the stack, and then recalled again
  57. whenever GOOD_TIMES returns.  Follow all that?
  58.     Wel the problem arises when you have too many nested or looped
  59. procedure calls, then too much data gets stuck on the stack and it fills
  60. up, giving you an out of stack erorr, so:
  61.  
  62. Procedure GOOD_TIMES
  63.  
  64. y=1002
  65. x=1232
  66.  
  67.  
  68. For I=1 to 50
  69. proc GOOD_TIMES
  70. Next I
  71.  
  72. End Proc
  73.  
  74. Will quickly use up the stack since each time GOOD_TIMES is called anew x
  75. and y are dumped on the stack not to be cleared until the new GOOD_TIMES
  76. returns. (which I actually think is never in this case)  So too many x's
  77. and y's build up on the stack (yup even though they all have the same
  78. value, since Amos doesn't know that) and you get an out of stack error. 
  79. Hpe that clears things up a bit, I deleted your bit of code before I could
  80. see where your stack error was but bottom line too many looped procedure
  81. calls or Gosubs (Gosub exhibits the exact same problem, this time because
  82. the old location (where to return to) is stored on the stack ) 
  83.  Well hope that wasn't too dense.  Let me know if you've anymore
  84. questions, and happy coding!
  85.